The invention relates to the general field of telecommunications.
It relates more particularly to managing the registration of users in a multimedia Internet protocol (IP) core network, such as for example a core network making use of the voice over IP (VoIP) technology and implementing an IP multimedia system (IMS) architecture, as defined in the third generation partnership project (3GPP) standard.
In known manner, voice over IP core networks are exposed to world of the Internet and its nuisances, in particular in terms of attacks and attempts at usurping identities specific to IP networks. The parties involved in implementing standards (and in particular telephone operators) who participate in defining these new telecommunications standards are thus concerned to propose security procedures that are irreproachable in order to avoid users suffering from the inconveniences that result from identity thefts.
For IMS core networks, there is provision to implement such procedures in particular when registering users (or in equivalent manner, when registering their terminals) with the core network. The way a user is registered with an IMS core network is set out in 3GPP documents TS 23.228 and TS 24.229.
In well-known manner, a subscriber is made known with an IMS core network by means of a subscription, in which various identities of the user are declared, namely:                the user's public identity (e.g. telephone number, contact name, session initiation protocol uniform request identifier (SIP URI)), or IP multimedia public user identity (IMPU), which are associated with information about the services to which the user has subscribed (in other words the user's service profile); and        the user's private identity or IP multimedia private user identity (IMPI), which is usually generated by the operator of the IMS core network in random manner in the network access identifier (NAI) format as defined in Document RFC 4282 published by the Internet Engineering Task Force (IETF), which private identity is associated with information for authenticating the user (e.g. a password).        
These public and private identities are stored in a user (or subscriber) data server of the core network that is also known as a home subscriber server (HSS). Both identities are needed to enable a user to register with the IMS core network.
In its present state, the 3GPP standard provides for a plurality of authentication procedures that can be applied when registering a user with an IMS core network. One of these procedures is the SIP Digest method, that is commonly implemented in the industry and in particular by core network operators.
To simplify the following description, the term “registering a user's terminal with an IMS core network” and “registering a user with an IMS core network” are used interchangeably.
FIG. 1 shows the main steps performed in a known example of the state of the art while registering a user during an authentication procedure that makes use of the SIP Digest method. This prior art example is the result of the IMS core network industry modifying the specifications of the 3GPP standard in order to enable the SIP Digest method to be used when registering a user.
The main entities involved during this procedure are firstly the user's terminal or “user equipment” (UE), and secondly in the IMS core network, a proxy call session control function (P-CSCF) server, an interrogating call session control function (I-CSCF) server, a serving call session control function (S-CSCF) server, and an HSS. The I-CSCF and S-CSCF servers dialog with the HSS via the Diameter Cx/Dx interfaces.
The function of each of these entities and of the Diameter Cx/Dx interfaces are known to the person skilled in the art and are therefore not described in detail herein. Only those elements that are necessary to understanding the invention and its context are described in detail below.
With reference to FIG. 1, the user's terminal UE sends a first registration request REGISTER to the P-CSCF server of the IMS core network, which request complies with the SIP protocol (step E10).
This first request contains the public identity IdPub of the user, together with a contact address for the terminal UE in the network. Nevertheless, the user is not required to provide the user's private identity during this first registration request.
On receiving this first request, the P-CSCF server interrogates a domain name server (DNS), not shown in FIG. 1, in order to obtain the address of the I-CSCF server of the nominal network of the user of the terminal UE.
Thereafter it forwards the first registration request received from the terminal UE to the I-CSCF server specified by the DNS (step E20).
On receiving this first request that contains only the public identity IdPub of the user of the terminal UE, and in application of the 3GPP standard, the I-CSCF server generates a private identity IdPrivd for the user. In the example shown in FIG. 1, this private identity IdPrivd is derived from the public identity IdPub (step E30) in the manner described in paragraph §5.3.1.2 of Document TS 24.229.
Thereafter, the I-CSCF server interrogates the HSS of the IMS core network with a user authorization request (UAR) in compliance with the Diameter protocol, which request contains the pair constituted by the public identity IdPub received in the first registration request and the private identity IdPrivd derived from the public identity IdPub by the I-CSCF server (step E40). This interrogation seeks to check that the user associated with these identities is indeed authorized to register with the IMS core network.
In the example of FIG. 1, on receiving the UAR, the HSS detects that the private identity IdPrivd is an identity derived from the public identity IdPub in compliance with the derivation procedure described in Document TS 24.229.
It then verifies that the user of the terminal UE is entitled to register with the IMS core network on the basis solely of the public identity IdPub used by the terminal UE (step E50). In other words, the checking performed by the HSS is limited to verifying that the public identity IdPub provided by the terminal UE in the first registration request does indeed correspond to a user known to the core network (i.e. a user who has been declared during a prior subscription with the operator of the core network), and is thus authorized to register therewith.
Where applicable, the HSS sends a Diameter user authorization answer (UAA) message to the I-CSCF server indicating that the user associated with the public identity IdPub is known and entitled to register with the core network. In this answer message, it also specifies the capabilities that are necessary for the S-CSCF server that is to be selected for registering the terminal UE, and also capabilities that are optional (step E60).
On receiving this answer message, the I-CSCF server selects an S-CSCF server having the capabilities specified by the HSS, and transfers the first registration request received from the terminal UE to the S-CSCF server as selected in this way (step E70).
On receiving the first request for registering the terminal UE, the S-CSCF server creates a context associated with the terminal UE and starts authenticating it.
To this end, it requests information from the HSS enabling the terminal UE to be authenticated by means of a Diameter multimedia authentication request (MAR) (step E80). In accordance with the Diameter interface specified between the S-CSCF server and the HSS, this MAR contains the public identity IdPub contained in the registration request together with the private identity generated by the S-CSCF server for the user (e.g. the private identity IdPrivd).
In response to this request, the S-CSCF server receives, via a Diameter multimedia authentication answer (MAA) message, the private identity IdPriv together with the password MdP of the legitimate user associated with the public identity IdPub, as registered when taking out the subscription with the HSS in association with the public identity IdPub (step E90). This information is naturally encrypted to ensure that it is kept confidential. It is stored in the previously created user context.
For obvious security reasons, it should be observed that the private identity IdPrivd as registered with the HSS when the legitimate user of the public identity IdPub takes out a subscription is generally different from the private identity IdPrivd that can be derived from the public identity in application of the recommendations of the 3GPP standard.
The S-CSCF server then returns a 401 Unauthorized answer to the terminal UE containing a challenge, so that the terminal UE uses its own password to calculate a user authentication result (step E100).
The terminal UE evaluates the user authentication result R with the help of the challenge communicated by the S-CSCF server (step E110).
Thereafter it sends a second registration request REGISTER to the P-CSCF server containing its public identity IMPU, its private identity, and the user authentication result R that it has just evaluated (step E120).
The private identity inserted by the terminal UE in the second request REGISTER as sent to the P-CSCF server is written IdPriv′.
The P-CSCF server relays this second request to the I-CSCF server (step E130).
The I-CSCF server detects that the second request REGISTER contains a public identity IdPub and a private identity IdPriv′ of the user of the terminal UE.
It then interrogates the HSS using a Diameter UAR containing the pair formed by the public identity IdPub and the private identity IdPriv′ received in the second registration request, and it does this in order to determine whether the user associated with these two identities is authorized to register with the IMS core network (step E140).
Two situations can then arise:
1) the HSS detects that the private identity IdPriv′ extracted from the second registration request is derived from the public identity IdPub in compliance with the derivation procedure described in Document TS 24.229: under such circumstances, and as described above, the HSS verifies that the user is entitled to register with the core network solely on the basis of the public identity IdPub (step E150); or
2) the private identity IdPriv′ is considered by the HSS as being not derived from the public identity IdPub in the meaning of the 3GPP standard: under such circumstances, the HSS checks the entitlement of the user to register with the core network on the basis of the pair formed by the public identity IdPub and the private identity IdPriv′ contained in the UAR (step E150). In other words, the user of the terminal UE will be authorized to register only if the private identity IdPriv′ specified by the terminal UE in the second registration request matches the identity IdPriv stored in the HSS (as declared in association with the public identity IdPub when the user took out the subscription with the IMS core network).
Where appropriate, the HSS sends a positive Diameter UAA to the I-CSCF server informing it that the user associated with the identities (IdPub, IdPriv′) is indeed known to the core network and is entitled to register (step E160).
On receiving this positive UAA, the I-CSCF server transfers the second registration request received from the terminal UE to the S-CSCF server associated with this terminal during step E70 (step E170).
If the UAA is negative, the registration request of the user of the terminal UE is rejected by the I-CSCF server (not shown).
The S-CSCF server verifies that the authentication information (IdPub, IdPriv′, and R) provided by the terminal UE matches the information (IdPub, IdPriv, and MdP) provided by the HSS (step E180) and gives an answer to the terminal UE as a function of the result of this verification (step E190).
If the second registration request is rejected by the S-CSCF server, it informs the terminal UE of the grounds for this rejection in its answer message sent to the terminal UE (e.g. mismatch between the private identity IdPriv′ and the private identity IdPriv, or indeed mismatch between the passwords). This message is relayed by the I-CSCF server to the terminal UE via the S-CSCF server.
Unfortunately, this authentication procedure presents a weakness in terms of security, and a computer pirate can easily take advantage of this known mode of operation for the entities I-CSCF, HSS, and S-CSCF in order to attempt attacks on the password or on the private identity of a legitimate user, these attacks being based on the legitimate user's public identity.
Specifically, it is easy for a computer pirate in application of the recommendations of the 3GPP standard to derive the private identity IdPrivd from the public identity IdPub, and to deliver this derived private identity to the IMS core network in the second registration request (i.e. IdPriv′=IdPrivd).
This second registration request is then propagated to the S-CSCF server as described above with reference to FIG. 1, and this occurs even if the private identity IdPrivd does not match the private identity IdPriv stored in the HSS in association with the public identity IdPub.
Because of the mismatch between the private identities IdPrivd and IdPriv, the S-CSCF server will indeed reject the second registration request sent by the computer pirate. However it will simultaneously inform the computer pirate of the grounds for the rejection (mismatch between the private identities or between the passwords).
Such information can be extremely precious for the computer pirate, since the pirate is informed about how well the attack is progressing. The pirate can then attempt to find the correct private identity and the correct password of the legitimate user of the public identity IdPub by brute force, i.e. by making multiple authentication attempts with the S-CSCF server.